home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 933 < prev    next >
Encoding:
Text File  |  1996-08-05  |  1.7 KB  |  45 lines
  1. Newsgroups: comp.lang.c
  2. Path: news.ridgecrest.ca.us!owens!mcclung
  3. From: mcclung@owens.ridgecrest.ca.us (Scott McClung)
  4. Subject: Re: Alignment restrictions...
  5. X-Nntp-Posting-Host: owens
  6. Message-ID: <DKyBK5.5r6@ridgecrest.ca.us>
  7. Sender: usenet@ridgecrest.ca.us (Ridgenet Usenet admin)
  8. Organization: Science Applications International Corporation
  9. References: <DKxHxG.EK1@ridgecrest.ca.us> <821232137snz@genesis.demon.co.uk>
  10. Date: Wed, 10 Jan 1996 06:04:53 GMT
  11.  
  12. In article <821232137snz@genesis.demon.co.uk>,
  13. Lawrence Kirby  <fred@genesis.demon.co.uk> wrote:
  14.  
  15. > What are the byte order conventions in the 'image file'? What you
  16. > have here assumes big endian while the code at the top just assumes
  17. > the byte order is the same as the target variable. In the latter
  18. > case this problem is easily solved by:
  19. >
  20. >    memcpy(&value, ptr, sizeof value);
  21.  
  22. Big endian.  The files are RLA images, animation frames, generated
  23. by Composer from WaveFront.  The program converts RLA to YUV.
  24.  
  25. > I suspect that the tailored inline code that a good compiler can
  26. > generate for memcpy, especially with a fixed, small size would be
  27. > difficult to beat.
  28.  
  29. I guess I'll check the assembly output of the compiler to make sure
  30. that it's really putting the memcpy() calls inline.  Often I'm not
  31. aware of what optimizations the compiler I'm using is capable of,
  32. beyond the basics, so it seems easier to assume that it will generate
  33. sub-optimal code in situations like this.  That's why I took the
  34. original memcpy() calls out, actually, and started trying to optimize
  35. some of these simple operations.
  36.  
  37. Thank you very much for the advice.
  38.  
  39. -- 
  40. /* Scott McClung                   Opinions expressed here are mine.
  41.  * UNIX Software Engineer/UNIX System Admin
  42.  * mcclung@imt.saic.com
  43.  * mcclung@ridgecrest.ca.us
  44.  */
  45.